Ninety milliseconds

The search box took 240 milliseconds to return results and everyone agreed it felt slow. We spent a month getting it to 90. Everyone still agreed it felt slow. That month taught me more than the six before it.

The problem was never the wait. It was that the page went blank while it waited, and a blank page is an admission that the software has lost its place. Two hundred and forty milliseconds of confident stillness reads as instant. Ninety milliseconds of flicker reads as broken.

What actually changed the feeling

Three things, none of which touched the server.

• The old results stay on screen, dimmed slightly, until the new ones are ready. Nothing ever empties.
• The first keystroke commits: the layout reserves the space it will need, so nothing below the box moves when results arrive.
• Anything under 120 milliseconds gets no spinner at all. A spinner that appears and vanishes is a small alarm, and users count alarms.

After those three, the same 240ms build tested as faster than the 90ms one. We shipped the fast server anyway — the two are not in competition — but the order matters. We could have had the feeling in an afternoon and spent the month on something else.

The uncomfortable part

Perceived performance has a reputation as a trick, a way of lying to users about work you did not do. I understand the suspicion and I think it is backwards. The user is not asking how many milliseconds elapsed. They are asking whether the software is still with them. That is a real question, and the honest answer is a design problem, not a benchmark.

The dishonest version is the progress bar that fills to ninety percent and waits. That one lies about the shape of the wait. Keeping the last good state on screen does not lie about anything. It just declines to panic.